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ABSTRACT 



A method and system which utilize a graphical user interface 
to identify potential participants in a teleconference, specify 
a user-controlled dial -up/hang-up order, and monitor the 
status of participants to the teleconference. The method and 
system receive conference commands from a World Wide 
Web (WWW) browser and translate the conference com- 
mands into commands that control a telephone bridge. 

24 Claims, 5 Drawing Sheets 
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PERSONAL WEB-BASED 
TELECONFERENCING METHOD AND 
SYSTEM 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to a method and system for 
establishing teleconferences. More specifically, the present 
invention relates to a new and improved method of estab- 
lishing dial-out, multi-party teleconferences without the 
need for human operator support or reservations made in 
advance. 

2. Description of the Background 

Known teleconference systems are generally classified 
into one of two types of systems: 1) dial- in conferences and 
2) dial-out or dial-up conferences; however, both types of 
systems are used for establishing teleconferences, i.e., tele- 
phone communications between two or more parties. Stan- 
ley et al., U.S. Pat. No. 4,635,251; and Frey et al., U.S. Pat. 
No. 4,577,065; disclose dial-in conference systems. Before 
a dial-in conference is established, a reservation is made in 
advance with an operator (or automated equivalent), typi- 
cally a few days before the teleconference. The reservation 
made in advance includes the time at which the teleconfer- 
ence will begin and the names or phone numbers of the 
parties that have been invited to participate. The operator 
reserves for the specified time a portion of a specialized 
telephone switch, called a bridge, which will join or 
"bridge" calls from each participating caller with each of the 
other callers. Examples of known bridges are 1) the LNX 
2000 by Excel and 2) the SDS-500 by Summa Four Inc. At 
the reserved time, callers dial into a centralized telephone 
number, typically an 800-number, and are added to the 
conference, based on their calling telephone number, the 
participants name, a conference identification or other suit- 
able identifying means. The system, however, has the dis- 
advantages of: 1) using reservations made in advance which 
prevent spontaneous teleconferences, and 2) not always 
indicating who is present on the teleconference at any given 
time. 

Known dial-out or dial-up conference systems, such as 
those disclosed in Yunoki, U.S. Pat. No. 5,408,518; and 
Hogan et al., U.S. Pat. No. 5,483,587; use reservations made 
in advance and operate similarly to the dial-in conference. 
However, in dial-out conferences the bridge uses the infor- 
mation in the reservation made in advance to call the 
participants individually. As each new participant accepts 
the invitation to join, the bridge connects the new participant 
with any other participants, thereby forming the teleconfer- 
ence. Disadvantages of this type of dial-out system are that: 
1) the conference initiator does not have control of the order 
of dialing or the removal of unwanted parties, and 2) a 
reservation has to be made in advance to use the system. 

SUMMARY OF THE INVENTION 

The present invention addresses the deficiencies of known 
systems 1) which do not provide user-controlled dialing, 2) 
which do not display the status of participants, 3) which 
require reservations to be made in advance, and 4) which 
require operator intervention to establish a teleconference. 
The present invention utilizes a graphical user interface to 
identify potential participants in a teleconference, specify a 
user-controlled dial-up/hang-up order, and monitor the sta- 
tus of participants to the teleconference. The method and 
system receive conference commands from a World Wide 
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Web (WWW) browser and translate the conference com- 
mands into commands that control a telephone bridge. The 
best presently known mode of implementing the present 
invention is with a specially programmed general purpose 

5 microprocessor programmed using microprocessor-specific 
executable instructions and which communicates with a 
telephone bridge. The instructions are generated by compil- 
ing a high-level computer language program, assembling a 
low-level computer program, and linking the two to produce 

to an executable program. The executable program implements 
the method and system, and the executable instructions are 
written into a computer memory readable by the general 
purpose microprocessor. 

15 BRIEF DESCRIPTION OF THE DRAWINGS 

These and other aspects of the present invention will 
become clear to those skilled in the art in view of the 
description of the best presently known mode of carrying out 
the invention and the industrial applicability of the preferred 
20 embodiment as described herein and as illustrated in the 
several figures of the drawings. 

FIG. 1 is a schematic illustration of a general purpose 
computer for controlling a telephone bridge according to the 
25 present invention; 

FIG. 2 is a partial illustration of an exemplary computer 
form which is filled out during conference registration; 

FIG. 3 is a partial illustration of an exemplary computer 
form which is filled out during conference registration to 
30 provide billing information for a teleconference; 

FIG. 4 is a partial illustration of an exemplary computer 
screen which acts as a control interface for controlling the 
operation of a teleconference; 

FIG. 5 is an illustration of exemplary computer icons 
35 which indicate the status of teleconference participants; 

FIG. 6 is a partial illustration of an exemplary computer 
form which details the charges incurred during a telecon- 
ference which requires a $5.00 minimum charge; 
40 FIG. 7 is a partial illustration of an exemplary computer 
form which allows problems with the teleconference to be 
reported during a post-teleconference "wrap-up"; 

FIG. 8 is a schematic illustration of a general purpose 
computer system connected to a telephone bridge for con- 
45 trolling teleconferences; and 

FIG. 9 is a schematic illustration of components used to 
receive requests from the WWW browser, process the 
requests, send commands to the bridge and receive status 
responses from the bridge. 

50 DETAILED DESCRIPTION OF THE 

PREFERRED EMBODIMENTS 

Referring now to the drawings, wherein like reference 
numerals designate identical or corresponding parts 

55 throughout the several views, FIG. 1 is a schematic illus- 
tration of a computer system for controlling teleconferences 
according to the present invention. A computer 100 imple- 
ments the method of the present invention, wherein the 
computer housing 102 houses a motherboard 104 which 

60 contains a CPU 106 and memory 108. The computer 100 
also includes plural input devices, e.g., a keyboard 122 and 
mouse 124, and a display card 110 for controlling monitor 
120. In addition, the computer system 100 further includes 
a floppy disk drive 114 and other removable media devices 

65 (e.g., compact disc 119, tape, and removable magneto- 
optical media (not shown)), a hard disk 112, or other fixed, 
high density media drives, connected using an appropriate 



08/30/2004, EAST Version: 1.4.1 



US 6,563, 

3 

device bus, e.g., a SCSI bus or an Enhanced IDE bus. 
Although compact disc 119 is shown in a CD caddy, the 
compact disc 119 can be inserted directly into CD-ROM 
players which do not require caddies. Also connected to the 
same device bus or another device bus, the computer 100 5 
may additionally include a compact disc reader/writer 118 or 
a compact disc jukebox (not shown). To receive control 
requests from participants, to send status information and to 
establish communications with other computers, the com- 
puter 100 is equipped with a communications adapter (not 10 
shown) which connects directly or indirectly to the Internet, 
an Intranet or a Local/Wide Area Network. The communi- 
cations adapter may be any one of the wired or wireless 
communication devices that can be attached to a computer, 
including, but not limited to, a modem (telephone- or 15 
cable -based), an infra-red transceiver, an Ethernet card, a 
Token-ring card, an ATM adapter, an Asymmetric Digital 
Subscriber Line, a "Fire -wire", or a universal serial bus. In 
addition, the present invention can be implemented by a 
set-top box which provides WWW services (e.g., WebTV). 20 
In addition, a printer (not shown) also provides printed lists 
of teleconference information. 

The system further comprises at least one computer 
readable media. Examples of such computer readable media 
are compact discs, hard disks, floppy disks, tape, magneto- 2 5 
optical disks, PROMS (EPROMS, EEPROMs, Flash 
PROMs), DRAM, SRAM, etc. Stored on any one or on a 
combination of the computer readable media, the present 
invention includes software for controlling both the hard- 
ware of the computer 100 and for enabling the computer 100 30 
to interact with a human user. Such software may include, 
but is not limited to, device drivers, operating systems and 
user applications, such as software development tools. Such 
computer readable media further includes the computer 
program product of the present invention for real-time 35 
control of teleconferences via requests received from users 
at remote sites. 

To provide the teleconference service, the present inven- 
tion utilizes a WWW server which "listens" for connection 
requests on a specified TCP/IP ports (e.g., port 80 for HTTP 40 
and port 443 for HTTPS). When a user wishes to establish 
a teleconference with other potential participants, the user 
connects to the WWW server using a conventional WWW 
browser, such as Netscape Navigator by Netscape Commu- 
nications or Internet Explorer by Microsoft Corporation, and 45 
specifies the URL which identifies the request as a telecon- 
ference initiation request. An exemplary URL (Universal 
Resource Locator) which would identify the request as a 
teleconference initiation request is: 

http://www.tpsinc.com/ptc 50 
where "http" specifies that the request should be made using 
the HyperText Transfer Protocol, "www.tpsinc.com" indi- 
cates the name of the machine on which the WWW server 
resides, and "/ptc M indicates the local resource on the WWW 
server to be retrieved. It is preferable that the WWW 55 
browser support "forms" as defined by the HTML 2.0 
standard and by the proposals for HTML 2.0+ and HTML 
3.0. This allows information to be gathered more compactly 
than can be gathered with a WWW browser that does not 
support forms. In addition, the preferred embodiment gen- 60 
erates "cookies" at the WWW server when a conference is 
requested and utilizes the "cookies" as part of the commu- 
nication between the WWW browser and WWW server. 
Other methods of saving state can also be used depending on 
the capabilities of the WWW browser that the user is using. 65 
Hidden fields in forms can be used to identify a 
teleconference, or additional parameters can be used to 
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create an augmented URL which identifies the conference. 
The use of "cookies" will be explained in more detail below. 

After the WWW browser connects to the WWW server, 
the WWW browser is sent a series of text and HyperText 
Markup Language (HTML) commands from the WWW 
server. The WWW browser interprets the HTML commands 
and renders the text as a screen or a form. One such form is 
shown in FIG. 2. FIG. 2 illustrates that multiple names and 
phone numbers can be entered into the form to identify the 
potential participants of the teleconference. This information 
and the remaining information and Web pages are transmit- 
ted between the WWW server and the WWW browser 
securely to ensure that others cannot detect credit card 
numbers or information about the phone calls. Although the 
screen is shown as having slots for six participants, more or 
fewer entries can be provided depending upon the capabili- 
ties of the bridge or constraints established by the service 
provider. For users unfamiliar with the operation of the 
teleconference system, help can be obtained by clicking 00 
the "Help" button on the form, or a demonstration can be 
displayed by clicking on the "Demo" button. Help and 
demonstration files can then be provided to the user in the 
form of HTML documents, audio prompts or even MPEG 
videos. In addition to dynamic demonstrations, static tutorial 
text and images can be sent to the browser for display. Also, 
after numbers (and potentially names) have been entered 
into the form, a user can select the "Rate" button to 
determine the cost per minute of the teleconference on a 
participant-by-participant basis. This allows a user to esti- 
mate the cost of a teleconference before it is started. When 
the numbers of the participants have been entered and the 
user is ready to initiate a teleconference, the user selects the 
"Begin Conference" button and the information in the form 
is submitted to the WWW server. 

The WWW server responds by sending to the user a 
second form, such as the one shown in FIG. 3. The second 
form is filled in by the user to specify a method of payment 
for the teleconference. Since credit cards are the most 
convenient and universally used method of electronic 
payment, the preferred embodiment uses credit card infor- 
mation to authorize the teleconference. Other embodiments 
include other methods of electronic payment such as elec- 
tronic cash transfers with a PIN or electronic payments such 
as those available by systems produced by CyberCash. After 
the card, or other payment information, has been entered, the 
user selects the "Submit" button to send to the information 
to the WWW server for authorization. If there are any 
incorrect values in the information or there are any holds on 
the credit card, the teleconference will not be initiated and 
the user is asked to re-enter the information or choose 
another method of payment. 

If the payment method is authorized, the WWW server 
pre -authorizes a minimum charge and sends the browser the 
control interface, such as the one shown in FIG. 4. Initially 
all the telephone icons are shown as displayed, using the 
icon which indicates the "on-hook" status. FIG. 5 illustrates 
that for this interface, the on-hook icon is a telephone with 
the telephone handset resting in the cradle. Typically a user 
will begin by connecting himself/herself to the teleconfer- 
ence first. To do this, the user clicks or otherwise selects the 
icon with the user's phone number. In FIG. 4, the user has 
selected the icon labeled "Me" and the bridge has called the 
user. However, this requires that the user not be using his 
phone line already to control the WWW browser. If the user 
has a dial-up connection, a second phone line will have to be 
used to receive the phone call. 

Periodically the WWW browser sends status requests to 
the WWW server to "refresh" its status information and 
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determine if any of the participants have changed their 
statuses since the last check. This periodic refresh is per- 
formed by including in the HTML document the "meta" 
command to refresh the data, along with a refresh interval. 
However, the WWW browser only performs the refresh 5 
while the user is displaying the HTML page or document 
with the refresh tag. If the user selects another URL, the user 
loses the ability to track status information. Using a periodic 
check of the status, as shown in FIG. 4, the user is shown 
that not only has the user selected the number corresponding 10 
to the user, the user has answered the phone as indicated by 
the "off-hook" telephone icon. 

After having completed the first connection from the 
bridge to the user, the bridge will play an announcement (if 
possible) to the user indicating that the user is being invited 15 
to participate in a teleconference. Jf the Juser wisheslto, 
participate , the user remains ori the lines Some bridges are 
not capable of playing voice announcements to participants 
as they join. If the bridge is not capable of playing a voice 
announcement to the user, the user will simply hear silence 20 
until the next participant is added. 

When the user is ready to contact the next participant, the 
user selects the icon corresponding to the next participant to 
be contacted. By^electing thejcon, aj^t^sj to^ajj^ next^ 
participaht i s sent fr om Jhe_WWW browser _"to Jthe. WWjV' 25 
^server^In FIG. 4, the user has selected "Person2" as the next 
participant to be added, and the user's request is acknowl- 
edged by providing a response to the HTML request which 
includes an indication that the icon of "Person2" should be 
displayed as a hand dialing the phone. When "Person2" 30 
answers the phone, the bridge connects "Person2" with any 
other participants — in this case the user. The next time the 
WWW browser refreshes its status information, the user will 
be sent information indicating that "Person2" has gone 
off-hook, and the display will be updated so that "Person2" 35 
also has the off-hook icon. 

Additional participants that were set-up during the call 
initiation phase and that have icons can be called in a manner 
similar to the manner shown above for calling "Person2". In 
addition, if the user wishes to disconnect a participant from 40 
the conference call, the user can select an off-hook icon to 
send the WWW server a hang-up request. The WWW server 
will send the bridge a command to remove the selected 
participant from the conference. Communication between 
the WWW server and the bridge is discussed in more detail 45 
below. Also, it is possible that at the end of a conference the 
user wishes to disconnect all participants simultaneously. To 
do so, the user selects the "End Conference" button and the 
WWW server receives the request which is translated into a 
bridge command to stop the teleconference. 50 

It is also possible that during the teleconference the user 
determines that a number entered for a participant is incor- 
rect. If the user selects an invalid number, the WWW server 
will respond by sending status information and an icon to the 
user to indicate that the phone number is invalid. An 55 
example icon indicating an invalid phone number is shown 
in FIG. 5. Another possible error condition that can occur is 
that there are no additional outbound lines with which the 
bridge can call participants. If this happens when a user has 
selected a number to be dialed, the WWW server sends the 60 
status information and the icon for this condition back to the 
WWW browser. An exemplary icon for this condition also is 
shown in FIG. 5. 

Even with correct numbers entered for the participants, it 
is also possible that the teleconference as initially configured 65 
will not meet the user's needs. If the user wants to add a new 
participant that he/she had not originally thought of, the user 
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selects the "Change Participants" button. In response, the 
WWW server will send back (and the WWW browser will 
re-display) the Teleconference Setup screen complete with 
all the existing numbers, but the "Begin Conference" button 
is replaced with a "Return to Conference" button. The user 
can then change any of the information for participants that 
are on-hook. The additions/changes are submitted to the 
WWW server by selecting the "Return to Conference" 
button, and the Teleconference Control screen is redisplayed 
based on the new information. 

When a teleconference is complete, either when all the 
participants have hung up or after the user selects the "End 
Conference" button, the user is provided a summary of the 
charges that have been incurred. An exemplary form show- 
ing the charges broken down by participant is shown in FIG. 
6. In FIG. 6, the system is assumed to have a $5.00 minimum 
charge, so the $1.30 total cost is actually rounded up to 
$5.00. 

During the post -teleconference wrap-up, it is also possible 
to report problems with the teleconference. FIG. 7 shows an 
exemplary form for reporting problems back to the WWW 
server and receiving automatic credits. Two problems that 
are displayed on the form are: 1) Noise on the line, and 2) 
Disconnected. The user may indicate that either or both of 
the conditions occurred by selecting their corresponding 
check-boxes. If either of the conditions occur, the user is 
given a credit to allow the user to reconnect without paying 
for the lost time. To avoid fraud, credits are not provided for 
more than one minute per leg of any particular call. Calls 
that continue longer than one minute clearly have provided 
value to the user. If the line had been truly unusable, the user 
could have just selected hang-up and restarted. 

While a conference is proceeding, it is possible to exceed 
the pre -authorized amount originally authorized by the 
WWW server when the teleconference was established. 
Four alternate embodiments of the present invention provide 
alternate responses to what happens when the pre-authorized 
limit is exceeded. In the first embodiment, the teleconfer- 
ence is simply cut-off when the pre-authorized limit has been 
exceeded. In the second embodiment, the WWW browser is 
updated to request that the user pre-authorize an amount 
equal to the original pre-authorized amount. If this autho- 
rization is not given, then the teleconference is ended. 
However, the user may not be looking at the WWW browser 
at the time the call needs to be re-authorized, or the user may 
have directed his/her WWW browser to look at something 
other than the status information. In either case, the user 
would miss the opportunity to re-authorize. Therefore, in the 
third embodiment, an announcement is played via the bridge 
requesting that the user pre-authorize an amount equal to the 
original pre-authorized amount. In the third embodiment, the 
user can confirm using DTMF tones. In the fourth and 
preferred embodiment, the user is simply informed as part of 
the initialization process that any additional charges will be 
automatically charged to his/her account, then the user's 
payment method is re-authorized each time the user exceeds 
the existing pre-authorized amount. If the pre-authorization 
ever fails, the conference is terminated at the end of the 
pre-authorized amount. 

To avoid having to re-authorize frequently, the present 
invention pre-authorizes the payment method according to a 
statistical model of average conference length and cost per 
minute for each participant. Atypical pre-authorized amount 
for small conferences is $25, but for international or large 
conferences, several hundred dollars may be pre-authorized. 
Also, the pre-authorized amount may be changed if the 
number of participants changes during the teleconference, 
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especially if an international number is added. The confer- 
ence monitor 340 which tracks whether a conference soon 
will exceed its pre -authorized amount is discussed in greater 
detail with reference to FIG. 9. 

In an alternate embodiment, the WWW server also sends 5 
a running total of the teleconference back to the user with 
each status "refresh" request. This allows a user to better 
track the actual cost of a conference, especially with more 
costly international calls. 

To implement the present invention, as shown in FIG. 8, 
the computer 100 is connected using communications path 10 
203 via the communications adapter to an external network, 
preferably the Internet, but additional networks such as a 
satellite data network or bulletin board service are also 
possible. Communications channel 205 connects the com- 
puter 100 and the bridge 200 to allow the computer 100 to 15 
send commands to the bridge 200 and to receive status 
requests from the bridge 200. The communication channel 
205 can be either wired (e.g., Token ring, Ethernet, ATM) or 
wireless (e.g., infra-red). Also, the bridge 200 is connected 
via telephone lines 210 to the telephone network to connect 
to the teleconference participants. In an alternate 
embodiment, the telephone lines 210 are replaced by other 
known communication media, either wired or wireless. 

As shown in FIG. 9, when a request is received from a 
browser via a network (e.g., the Internet), the request is 
received by a WWW server 300 (e.g., an HTTP Daemon or 25 
an HTTPS (secure HTTP) Daemon) running on the com- 
puter system 100. If the request is for a static document, the 
WWW server 300 provides the document to the browser as 
part of an HTML reply without having to contact any other 
processes. If the request requires control of the switch or 30 
status information, the WWW server spawns a CGI program 
310 to handle the request. As would be appreciated by one 
of ordinary skill in the art, the CGI program 310 can be 
either a compiled program or an interpreted script. Presently 
the best known mode uses Perl scripts to implement the CGI 
programs 310 spawned by the WWW server 300. One 
advantage of Perl scripts is the ability to use TCP/IP sockets 
to communicate with other processes, such as the Program- 
mable Switch Matrix (PSM) Gateway 320. As shown in 
FIG. 9, in one embodiment of the present invention, depend- 
ing on the type of request, the CGI program either requests 
status information from a storage device 330 or issues a 
command to the PSM Gateway 320. Status information 
requested from the storage device 330 includes both infor- 
mation received from the bridge 200 (e.g., information such 
as the status of the connection of each participant), and 
information available from other sources (e.g., whether or 
not a payment method was authorized, participant name and 
telephone information, total cost of a teleconference). When 
returning status information, the CGI program reads the 
status information and formats the requested status infor- 50 
mation as HTML. The CGI program returns the HTML reply 
to the WWW server 300 which passes the HTML reply to the 
user via the external network. In systems which allow the 
WWW server 300 to pass the open socket to a child process 
and to close the original socket, the reply does not actually 55 
pass through the WWW server 300 but is passed directly 
from the CGI program 310 to the WWW browser. 

When the user requests that the bridge perform an action 
on the teleconference (e.g., end the conference, dial a 
number, disconnect a participant), the URL information is 
sent from the CGI program 310 to the PSM Gateway 320 60 
and the PSM Gateway 320 sends a command to a switch 
controller 350 that controls the bridge 200. In a first embodi- 
ment of the present invention, the switch controller 350 in 
FIG. 9 is implemented on a separate SPARC computer and 
executes the Programmable Switch Matrix connected to the 65 
PSM Gateway 320. The PSM and the switch controller 350 
communicate across the communication medium 205 as if 



the bridge 200 were another computer on a network. 
However, the bridge 200 can also be connected by a serial 
line hung off of the computer running the switch controller 
350 or any other of the communication adapters described 
above. In a second embodiment of the present invention, the 
processes 300, 310 and 350 are run on a single computer 
100, and there is no need for PSM Gateway 320 because all 
communication goes directly to the PSM. In a third embodi- 
ment of the present invention, the PSM is run on a second 
computer or integrated into the bridge 200. In both 
embodiments, the bridge 200 receives commands (including 
status requests) based on a bridge-specific command proto- 
col. 

One example of a communications message which is part 
of a communications protocol is listed below in Table I. 
Table I shows the appropriate byte sequence for command- 
ing the bridge to perform a requested action, and Table II 
shows the actual byte values of the command sequence. For 
commands with replies, Table III shows the byte values of 
a reply from the bridge 200. The structure of these replies 
have been taken from the LNX 2000 User's Manual, Excel 
Part Number 08-2003-02, incorporated herein by reference. 
The values of the replies are stored in the storage device 320 
(e.g., hard disk, flash memory, RAM). 

TABLE I 

Format of Byte Sequence 



Field 


Byte 


Description 


Frame Indicator 


0 


Always O x FE 


Length (NN) 


1 


Length of bytes to follow, not including 






the checksum 


API Message Type 


2 


Function type 


Sequence Number 


3 


Tb differentiate messages of the same 






type 


Data[0] 


4 


Data content of Message Type 


Data[ . . . ] 




Data content of Message Type 


Data[n] 


NN+ 1 


Data content of Message Type 


Checksum 


NN + 2 


Checksum 



40 



TABLE II 



Command Byte Values Sent to Switch 



0 x FE Frame Indicator 

0 x 05 Message Length 

0 x 4B Create Conference 

0 x 01 Seq. Number 

0 x 06 Conference Size (-6) 

0 x 01 Conference Type (1 = u-Law, 2 « A- Law, 3 = 

0 x 00 Broadcast (0 = disabled, 1 = enabled) 

0 x NN Checksum 



mixed) 



TABLE III 



Response Byte Values From Switch 



0 x FE 


Frame Indicator 


Ox 05 


Message Length 


0 x 4B 


Create Conference 


0 x 01 


Seq. Number 


0 x 10 


Status (0 x 10 «* ACK, anything else is error condition) 


Ox 00 


Conference ID (MSB) 


Ox 01 


Conference ID (LSB) 


0 x NN 


Checksum 



Throughout the processing of teleconferences, the PSM 
Gateway 320 has potentially managed more than one tele- 
conference simultaneously. In order to distinguish between 
teleconferences, the PSM Gateway 320 issues a "cookie" or 
WWW browser identifier to each WWW browser when each 
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user initiates a conference. To avoid forgeries, this cookie is 
based the date and time of the initiation, as well as the 
process ID of the CGI process that sent the initiation 
document. Together these parameters create a "unique" ID 
that is difficult to guess randomly. After the PSM Gateway 
320 has sent this cookie to the WWW browser via the CGI 
program 310, the WWW browser stores the cookie inter- 
nally and transmits the cookie back to the WWW server 300 
with each new command or status request. In this way, the 
PSM Gateway 320 can maintain a table in the storage device 
330 that maps control data structures to cookies thereby 
enabling the PSM Gateway to perform status updates to the 
storage device 330 on a per-teleconference basis. The cookie 
also enables the CGI program 310 to distinguish between a 
status request from a first browser and a status request from 
a second browser. 

The cookie also allows separate billing records to be 
maintained and checked by conference monitor 300. Con- 
ference monitor 340 "wakes up" periodically and checks the 
status of each line controlled by the bridge 200. For each 
active leg, the conference monitor 340 determines the cost 
incurred by the leg and a total cost for the corresponding 
teleconference. From this, the conference monitor 340 cal- 
culates whether or not a teleconference will soon exceed its 
pre-authorized limit. If so, the computer monitor 340 con- 
trols costs according to one of the four embodiments 
described above. 

Obviously, numerous modifications and variations of the 
present invention are possible in light of the above teach- 
ings. It is therefore to be understood that, within the scope 
of the appended claims, the invention may be practiced 
otherwise than as specifically described herein. 

What is claimed as new and desired to be secured by 
Letters Patent of the United States is: 

1. A computer program product, comprising: 

a computer storage medium and a computer program code 
mechanism embedded in the computer storage medium 
for causing a computer to control a telephone bridge 
linked to the computer, the computer controlling the 
telephone bridge based on commands from a graphical 
user interface of a non-operator, the computer program 
code mechanism comprising: 

first computer code configured to receive a message 
from the graphical user interface of the non-operator; 

second computer code configured to convert the mes- 
sage into a bridge command specific to the telephone 
bridge; 

third computer code configured to send the bridge 

command to the telephone bridge; 
fourth computer code configured to receive a response 

from the telephone bridge; and 
fifth computer code configured to send the response to 

the graphical user interface of the non-operator; 
wherein the fifth computer code comprises sixth computer 
code configured to transmit a cost per minute of a 
multiparty teleconference before the multiparty tele- 
conference is established. 

2. The computer program product as claimed in claim 1, 
wherein the first computer code comprises seventh computer 
code configured to receive a user-command as the message. 

3. The computer program product as claimed in claim 2, 
wherein the second computer code comprises eighth com- 
puter code configured to establish a multiparty teleconfer- 
ence between plural teleconferees based on the message and 
without a reservation made in advance. 

4. The computer program product as claimed in claim 1, 
wherein the eighth computer code comprises ninth computer 
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code configured to establish the multiparty teleconference 
using a connection message per teleconferees. 

5. The computer program product as claimed in claim 2, 
wherein the eighth computer code further comprises tenth 

5 computer code configured to disconnect all of the plural 
teleconferees from the multiparty teleconference based on a 
single disconnect message. 

6. The computer program product as claimed in claim 5, 
wherein the first computer code comprises seventh computer 
code configured to receive a status request the message. 

7. The computer program product as claimed in claim 3, 
wherein the fifth computer code comprises eighth computer 
code configured to transmit at least one of an icon and an 
icon identifier as part of the response to the status request 
such that at least one of the icon and an icon identified by the 

15 icon identifier is displayed by the graphical user interface as 
a status of a corresponding connection to one of the plural 
teleconferees. 

8. The computer program product as claimed in claim 3, 
wherein the first computer code comprises seventh computer 

20 code configured to receive a secure HTML request as the 
message. 

9. An apparatus for controlling a telephone bridge based 
on commands from a graphical user interface of a non- 
operator, the apparatus comprising: 

25 a first receiver for receiving a message from the graphical 
user interface of the non-operator; 
a converter for converting the message into the bridge 

command specific to the telephone bridge; 
a first transmitter for transmitting the bridge command to 
30 the telephone bridge; 

a second receiver for receiving a response from the 

telephone bridge; and 
a second transmitter for transmitting the response to the 
graphical user interface of the non-operator; 
35 wherein the second transmitter comprises a cost transmit- 
ting unit configured to transmit a cost per minute of a 
multiparty teleconference before the multiparty tele- 
conference is established. 

10. The apparatus as claimed in claim 9, wherein the first 
40 receiver is a receiver configured to receive a user-command 

as the message. 

11. The apparatus as claimed in claim 10, wherein the 
converter comprises a teleconference establishing unit con- 
figured to establish a multiparty teleconference between 

45 plural teleconferees without a reservation made in advance. 

12. The apparatus as claimed in claim 10, wherein the 
teleconference establishing unit comprises a connecting unit 
configured to establish the multiparty teleconference using a 
connection message per teleconferee. 

50 13. The apparatus as claimed in claim 12, wherein the 
teleconference establishing unit further comprises a discon- 
necting unit configured to disconnect all of the plural 
teleconferees from the multiparty teleconference based on a 
single disconnect message. 

55 14, The apparatus as claimed in claim 9, wherein the first 
receiver is a receiver configured to receive a status request 
as the message. 

15. The apparatus as claimed in claim 14, wherein the 
second transmitter comprises an icon transmitter configured 

60 to transmit at least one of an icon and an icon identifier as 
part of the response to the status request such that at least one 
of the icon and an icon identified by the icon identifier is 
displayed by the graphical user interface as a status of a 
corresponding connection to one of the plural teleconferees. 

65 16. The apparatus as claimed in claim 9, wherein the first 
receiver is a receiver configured to receive a secure HTML 
request as the message. 
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17. A computer-implemented method for causiog a com- 
puter to control a telephone bridge linked to the computer, 
the computer controlling the telephone bridge based on 
commands from a graphical user interface of a non-operator, 
the method comprising the steps of: 5 

receiving a message from the graphical user interface of 

the non-operator; 
converting the message into a bridge command specific to 

the telephone bridge; 
transmitting the bridge command to the telephone bridge; 
receiving a response from the telephone bridge; and 
transmitting the response to the graphical user interface of 

the non-operator; 
wherein the step of transmitting comprises transmitting a 15 

cost per minute of a multiparty teleconference before 

the multiparty teleconference is established. 

18. The method as claimed in claim 17, wherein the first 
step of receiving a message comprises receiving a user- 
command as the message. 20 

19. The method as claimed in claim 18, wherein the 
converting step comprises establishing a multiparty telecon- 
ference between plural teleconferees based on the message 
and without a reservation made in advance. 
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20. The method as claimed in claim 19, wherein the 
establishing step comprises establishing the multiparty tele- 
conference using a connection message per teleconferee. 

21. The method as claimed in claim 19, further compris- 
ing the step of disconnecting all plural teleconferees from 
the multiparty teleconference based on a single disconnect 
message. 

22. The method as claimed in claim 19, wherein the first 
step of receiving a message comprises receiving a status 
request as the message. 

23. The method as claimed in claim 20, wherein the step 
of transmitting the response comprises transmitting at least 
one of an icon and an icon identifier as part of the response 
to the status request such that at least one of the icon and an 
icon identified by the icon identifier is displayed by the 
graphical user interface as a status of a corresponding 
connection to one of the plural teleconferees. 

24. The method as claimed in claim 23, wherein the first 
step of receiving comprises receiving a secure HTML 
request as the message. 

***** 
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